⚙️ [Maintenance]: Require Pester 6.x in test files#16
Conversation
No Significant Changes DetectedThis PR does not contain changes to files that would trigger a new release:
Build, test, and publish stages will be skipped for this PR. If you believe this is incorrect, please verify that your changes are in the correct locations. |
Super-linter summary
All files and directories linted successfully For more information, see the GitHub Actions workflow run Powered by Super-linter |
There was a problem hiding this comment.
Pull request overview
This PR adds an explicit Pester 6.x requirement to the module’s test file to ensure the tests are discovered/executed only when an expected Pester major version is available.
Changes:
- Added
#Requires -Modules ...to lock the test file to Pester 6.x (with module identity pinned via GUID). - Introduced an explicit Pester minimum version requirement for test discovery.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
The GUID pins module identity (precise pinning), a stricter control than the lock-to-major risk appetite. Keep only the version range.
No Significant Changes DetectedThis PR does not contain changes to files that would trigger a new release:
Build, test, and publish stages will be skipped for this PR. If you believe this is incorrect, please verify that your changes are in the correct locations. |
Super-linter summary
All files and directories linted successfully For more information, see the GitHub Actions workflow run Powered by Super-linter |
Keeps the implemented-module README over main's placeholder, keeps PSModuleTest.Tests.ps1 removed (replaced by Confluence.Tests.ps1), applies the Pester 6.x requirement from #16 to Confluence.Tests.ps1, and picks up the Process-PSModule workflow bump to v5.5.7.
Confluence is now a working PowerShell module: connect to an Atlassian Confluence Cloud site once and manage pages, spaces, blog posts, folders, comments, labels, content properties, attachments, and restrictions as first-class PowerShell commands. This first version ports the generalized Confluence REST v2 client into the PSModule source layout and wires it to the Process-PSModule build. ## New: 41 Confluence commands Grouped by resource area: - **Auth** — `Connect-Confluence`, `Disconnect-Confluence`, `Get-ConfluenceContext` - **Config** — `Get-ConfluenceConfig`, `Set-ConfluenceConfig` - **API** — `Invoke-ConfluenceRestMethod` (the single generic REST entry point every command wraps) - **Spaces** — `Get-ConfluenceSpace`, `Get-ConfluenceSpacePermission`, `Get-ConfluenceSpaceProperty`, plus space administration: `New-ConfluenceSpace` (create), `Update-ConfluenceSpace` (partial update), `Set-ConfluenceSpace` (declarative create-or-replace), `Remove-ConfluenceSpace` (permanent, asynchronous delete) - **Site / Pages / BlogPosts / Folders / Comments / Labels / ContentProperties / Attachments / Restrictions / Users** — read/write commands per area; page edits use `Update-ConfluencePage` (renamed from `Set-ConfluencePage`, since it performs a partial update and the `Set` verb is reserved for declarative create-or-replace as in `Set-ConfluenceSpace`) Each command documents its required OAuth granular scope in its help, and errors surface Atlassian's `X-Failure-Category` (for example `FAILURE_CLIENT_SCOPE_CHECK`) so permission/scope failures are easy to spot. Every command's help links to its documentation page (`https://psmodule.io/Confluence/Functions/<Area>/<Command>/`) followed by the relevant Atlassian API reference. ## New: reusable connections via Context Credentials and module configuration persist through the [Context](https://github.com/PSModule/Context) module, declared via `#Requires` so the build records it as a manifest dependency. Connect once — the token is stored as a `SecureString`. Store multiple sites or accounts as named contexts and target any of them with `-Context`. ```powershell $token = Read-Host -AsSecureString Connect-Confluence -Site 'msxorg' -Username 'you@example.com' -Token $token -SpaceKey 'DOCS' $space = Get-ConfluenceSpace -Key 'DOCS' New-ConfluencePage -SpaceId $space.id -Title 'Release notes' -Body '<p>Hello</p>' ``` ## How it is built - One function per file under `src/functions/{public,private}`, grouped by resource area; module state in `src/variables/private`. - No `header.ps1` and no source `manifest.psd1` — the build generates the manifest, derives the module tags from the repository topics, and reads the `#Requires` (PowerShell 7.0 and Context) from the source. - Comment-based help follows the GitHub module style: indented sections, fenced examples, and a documentation-page `.LINK` first. - Examples (`Connecting`, `Pages`) and a credential-free surface test, plus a skipped integration scaffold that reads `CONFLUENCE_*` environment secrets. Tests require Pester 6.x. ## Tests and secrets No tenant-specific data is included — examples use generic placeholders. The integration tests are skipped unless connection details are provided through the repository's Actions secret and variables (`CONFLUENCE_SITE`, `CONFLUENCE_USERNAME`, `CONFLUENCE_API_TOKEN`, `CONFLUENCE_SPACE_KEY`), which this PR wires into the Process-PSModule workflow through `TestData`. Each public function also carries a `#SkipTest:FunctionTest` marker so the framework's source-code test suite passes while per-function tests are deferred. ## Technical details - Merged `main`: kept the implemented-module README over the placeholder (#15), adopted the Pester 6.x requirement (#16), and picked up the Process-PSModule workflow bump to v5.5.7 (#14). - Validated locally: 0 syntax parse errors, 0 PSScriptAnalyzer findings (repo linter and framework build rules), every public command's first `.LINK` resolves to its docs page, and the module assembles and imports with all 41 public functions. - Change type is **minor** (new functionality on a pre-1.0.0 module). Repository topics set to supply the manifest tags; `major`/`minor`/`patch`/`NoRelease` labels created for the release automation. - No linked issue — this work was driven directly; a tracking issue can be added for traceability. Opened as a **draft** for review.
Pester tests in this module now require the Pester 6.x major version, so every contributor and CI run resolves the same major and a new Pester major can't slip in and break the suite. The tests previously declared no framework requirement and ran on whatever Pester happened to be installed.
Changed: tests are locked to the Pester 6.x major
Every
*.Tests.ps1file now starts with a version-bounded requirement:#Requires -Modules @{ ModuleName = 'Pester'; ModuleVersion = '6.0.0'; MaximumVersion = '6.*' }Any Pester
6.xsatisfies it, so minor and patch releases flow in automatically while moving to a new major stays a deliberate, reviewed change. No module source or behaviour changes.Technical Details
#Requires -Modulesstatement to each test file undertests/; non-test files are untouched.ModuleVersion = '6.0.0'is the floor andMaximumVersion = '6.*'the wildcard major ceiling. Module-identity (GUID) pinning is intentionally omitted — it is a separate supply-chain control, not part of the lock-to-major risk appetite.